fix(cli): stop db start hanging on a stalled docker (CLI-2066) - #6530
Merged
7ttp merged 6 commits intoSep 10, 2026
Merged
Conversation
Contributor
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase/cli/supabase@0618b9ca599cf12f5f10f9f300d4e0229b84eee9Preview package for commit |
…db-start-hangs-silently-before
Member
Author
|
/ai-review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🤖 AI Review
Both reviews completed. After verification, the 10 reported findings merge into 9 distinct findings, all confirmed. No critical or major defects were identified; the findings comprise four minor reliability/coverage/observability concerns and five documentation or test-organization nits.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟡 MINOR | apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:126 |
reliability |
claude | The Engine probe has only a socket-inactivity timeout, so a peer that continually trickles data can keep the probe running far beyond two seconds. |
| 🟡 MINOR | apps/cli/src/commands/db/start/start.integration.test.ts:1832 |
test-coverage |
claude | The Windows named-pipe transport is not exercised by a real transport test or CI job. |
| 🟡 MINOR | apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:221 |
observability |
claude | The Engine request bypasses DebugLogger.http, so its debug output lacks the established HTTP-request format; optional layer-time logger lookup also makes missing wiring silent. |
| 🟡 MINOR | apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:134 |
test-coverage |
claude | Several new probe branches, including oversized and interrupted responses and debug tracing, lack tests. |
| ⚪ NIT | apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:81 |
documentation |
claude | The comments cite ControlHttpReader as precedent, but that symbol is not defined or referenced anywhere else in the repository. |
| ⚪ NIT | apps/cli/src/commands/db/start/start.integration.test.ts:1743 |
test-organization |
claude+codex | Tests for the shared local-db-running component are placed in the db-start handler suite instead of being colocated with their implementation. |
| ⚪ NIT | apps/cli/src/commands/start/services/vector.service.unit.test.ts:17 |
test-organization |
claude | Direct tests for platformDefaultDockerHost remained in the vector service suite after the helper moved to hostname.ts. |
| ⚪ NIT | apps/cli/src/commands/db/reset/SIDE_EFFECTS.md:127 |
documentation |
claude | db reset documents the new Engine request and Docker context files but omits the Docker environment variables now consumed in process. |
| ⚪ NIT | apps/cli/src/commands/db/start/SIDE_EFFECTS.md:121 |
documentation |
codex | The API side-effects table inaccurately says the Engine probe uses only the response status. |
Stats
Claude findings: 8 · Codex findings: 2 · Confirmed: 9 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5 + gpt-5.6-sol · Trigger: manual · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
Coly010
approved these changes
Sep 9, 2026
…db-start-hangs-silently-before # Conflicts: # apps/cli/src/command-internal/pgdelta-engine-runtime.layer.ts # apps/cli/src/commands/db/reset/SIDE_EFFECTS.md
![depthfirst-app[bot]](https://avatars.githubusercontent.com/in/1021002?s=60&v=4){kind=small}
7ttp
force-pushed
the
7ttp/cli-2066-windows-cli-21110-supabase-db-start-hangs-silently-before
branch
from
September 10, 2026 11:06
fcff359 to
b926687
Compare
…db-start-hangs-silently-before
7ttp
enabled auto-merge
September 10, 2026 11:24
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Sep 10, 2026
7ttp
deleted the
7ttp/cli-2066-windows-cli-21110-supabase-db-start-hangs-silently-before
branch
September 10, 2026 11:53
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
db startno longer hangs forever when thedockerCLI binary stalls: the already-running check now asks the Docker Engine API directly.What's hurting the users?
Since v2.110.0 the check spawns
docker container inspectand waits on it. If that binary hangs,db startshows nothing, starts nothing, and never exits (#6110). v2.109.1 was immune because it called the Engine API instead of spawning a subprocess...Now fixed by
The probe resolves the daemon endpoint the same way the docker CLI does (
DOCKER_HOST, then the context store, then the platform default) and sendsGET /containers/<id>/jsonover the local socket or named pipe.anything that is not a clean Engine 200 or 404 falls back to the old spawn path, so error messages,
daemon-down handling, and Podman support stay exactly as they are today.
db reset --local,db diff --use-pgadmin, and the declarative flows share the same probe and get the same fix...Ref
supabase db starthangs silently before contacting Docker #6110